FCrDNS, or forward-confirmed reverse DNS, or full-circle reverse DNS, also known as iprev, is a situation where a given IP address has forward (name-to-address) and reverse (address-to-name) DNS entries that match each other. The process of checking this is as follows (described as a Proposed Standard by RFC 5451, section 3; and previously outlined in RFC 1912, especially section 2.1):
DNS query type PTR on 192.0.2.4 --> returns PTR-record="hostname.example.com" (1 result) DNS query type A on "hostname.example.com" --> returns A-record=192.0.2.4 (1 result) Matches original IP address, therefore check passes
Important anti spam and email verification techniques such as SenderID and Sender Policy Framework, rely on the reverse lookup being correctly set. Without correct reverse lookup these systems cannot function, so it is very bad practice to have this incorrectly set. Many discerning anti spam systems will, quite correctly, reject email from smtp relays which fail this test.
A FCrDNS verification can create a weak form of authentication that there is a valid relationship between the owner of a domain name and the owner of the network that has been given an IP address. While weak, this authentication is strong enough that it can be used for whitelisting purposes because spammers and phishers can not usually by-pass this verification when they use zombie computers to forge the domains. It is considered good practice in general that all rDNS should be forward confirmed. This is especially true for the IP addresses used by email servers to help prevent outgoing email from being wrongly rejected as spam.
A FCrDNS verification can also establish that the network owner and the domain owner both have at least a very basic understanding of the RFCs and can correctly configure things. That is, they have followed the instructions in RFC 1033 on "Adding a host". There is a statistical correlation between machines that send spam and machines that fail FCrDNS checks, but correlation does not imply causation and many network owners simply can not configure the rDNS because their upstream providers either can't or won't delegate the rDNS..
However, zombie computers infected with spambots will not be able to fake the reverse DNS to make it match. The main reason behind the correlation between spamming machines and failing FCrDNS is that it generally cannot be faked or overridden by a spambot infested machine, and thus this check is very effective in controlling spam, underwritten and justified by supporting RFCs.
Common DNS misconfigurations are outlined in RFC 1912, of particular note is section 2.1 that states, under the heading "Inconsistent, Missing or Bad Data", "Make sure your PTR and A records match." Those ISPs that will not or cannot configure reverse DNS will generate problems for hosts on their networks, by virtue of RFCs being contravened when communicating with hosts that do follow the RFC guidelines. From a technical perspective reverse DNS is trivial to implement correctly and there is no reason not to implement it for hosts providing regular internet services. ISPs that cannot or will not provide reverse DNS ultimately will be limiting the ability of their client base to use internet services they provide effectively and securely.